The Let's Play Archive

SHENZHEN I/O

by Quackles

Part 36: Assignment #15: Carbine Target Illuminator

Carbine Target Illuminator



Guess who got stuck with this job? I'm not really at all happy with this, but Carl being able to say no is one of the perks of seniority in this case, I'd think.








The actual design seems quite straightforward. You listen on the inputs until you have an 'out' pulse followed by an 'in' pulse, take note of how much time passed between them, then use that to drive the laser and/or flood lights. It's a job that should be easy for a competent engineer.

I think I'm feeling pretty competent today...

[ ~ ]



 

First off: it looks like each of the inputs, radar-out and radar-in, obviously needs its own MC. The radar-out MC will send a signal to the radar-in MC on each time unit, indicating whether or not radar-out is on - this lets the radar-in MC know whether to count or reset its counter. Then, once that MC detects a pulse on radar-in, it'll start working on the sending output bit (which I haven't coded yet). It'll also send its count back to the first MC, because I think the first MC might need to do something with it. I'll figure that out when I get to work on the outputs.

[ ~ ~ ]



 
 

There we go! Outputs are half-done. It definitely seems like each output also needs its own MC, for result-testing purposes (though thankfully they're MC4000s or else I'd hardly be able to fit them on the board!).
It's pretty simple. The upper MC on the left sends the output to the top MC on the right, which handles the laser. The lower MC sends output to both bottom right MCs. (That's why it sends acc to x3 twice - so that each MC on the right can receive it once).

I just have to finish up the code for everything, and this'll be ready to go.

[ ~ ~ ~ ]



 
 

This is the final version. I had to upgrade the top right MC (controls the laser) to a MC6000. It's unfortunate - but you have to have a test for each possible value, and then you can only use the value from an XBus pin once, right? But I also read on ChipOverflow that you also have to store the value from an XBus pin before you use it, so that's 3 lines for each of 3-4-5-6. So, 4 * 3 = 12 lines = big MC.
(The same applies to the bottom right MCs, but there it's only 6 lines each because they only check two values, so they can stay MC4000s).
All the code is really clean and understandable, so it's not like I need to comment it or anything.

The only other big change is that I finished the code for the bottom right MCs, adding extra sends on the radar-in MC as necessary - the bottom-right MCs also each needed a slp 1 in their scripts - otherwise, they were eating the sends meant for their sibling.

And that's a wrap! ¥21, and 757 average power usage. I'd say that's the best I can do.



Yeah, Carl isn't all that happy... but I'll show him my design later.